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(57) Abstract: Authorizing a requesting entity to have a server perform a particular action in a manner that is at least partially 
independent of the underlying target data structure. An authorization station maintains a number of role templates (310) that each 
define basic access permissions with respect to a number of command methods. The authorization station also maintains a number of 
role definitions (350) that each define access permissions for specific requesting entities by using one or more of the role templates 
(310). When the authorization station receives a request from the requesting entity, the authorization station then identifies the 
appropriate role definition (350). Using this role definition (350), the authorization station determines access permissions for the 
requesting entity with respect to the requested action. 
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AUTHORIZING A REQUESTING ENTITY TO 
OPERATE UPON DATA STRUCTURES 
BACKGROUND OF THE INVENTION 
1. The Field of the Invention 
5 [0001] The present invention relates to the field of network security. Specifically, 
the present invention relates to methods, systems, and computer program products for 
authorizing a requesting entity to operate upon data structures in a standard manner 
that is at least partly independent of the type of underlying data structure being 
operated upon. 

10 2. Background and Related Art 

[0002] The success of the information age is widely attributed to the ability to 
efficiently access data. Data comes in a wide, almost unlimited, variety of different 
data types. For example, there may be data types corresponding to calendar 
information, task information, in-box information, word processing documents, 

1 5 presence information, favorite web site information, or a host of other different types 
of information. Often, it is desirable to control who has what kind of access to what 
kind of data. For example, a user or application might have read/write privileges over 
a small group of files, while having read-only privileges over another group of files. 
[0003] Conventionally, this was accomplished by using an Access Control List or 

20 ACL associated with each file or directory in a hierarchical directory tree structure. 
Typically, access control rights for a particular directory are inherited by any 
descendent directories or files unless expressly overwritten by an access control list at 
the descendent directory or file. When a request comes in to perform an operation on 
a particular target file or directory, the total access control for that request is defined 

25 by any access rights inherited as well as the express enumeration of access rights 
indicated in the corresponding access control list for the target file or directory. If 
appropriate for the total access control permissions corresponding to the target file or 
directory, the request is then processed. 

[0004] The use of access control lists thus allows for access control at the 
30 granularity of a file or directory. However, often certain parts of a file may be more 
sensitive than others. Regardless, the conventional use of access control lists provides 
the same level of access to all parts of a file. In other words, conventional access 
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control lists do not provide for granular access control below the file level. 
Accordingly, what is desired are methods, systems, and computer program products 
for providing more refined granular access control than the directory or file level. 
[0005) In addition, conventional access control lists grant the same level of access 
5 regardless of the way the user or application was authenticated. However, there are 
often a wide variety of authorization methods available, each offering a different level 
of confidence that a user or application requesting operation is indeed who it purports 
to be. It may not be appropriate to grant the same level of access to a user or 
application who used a relatively low security authentication method such as the 

10 simple assertion method as compared to a user or application that used a relatively 
high level of authentication. After all, it would be fairly easy for an imposter to 
simply assert that they were a particular authorized user or application. Accordingly, 
what is further desired are methods, systems, and computer program product for 
granting appropriate access privileges based on authentication credentials. 

15 SUMMARY OF THE INVENTION 

[0006] The present invention extends to methods, systems and computer products 
for authorizing a requesting entity to have a service perform a particular action in a 
manner that is at least partially independent of the underlying target data structure that 
is desired to be accessed. In one operating environment, there are a number of 

20 individuals and applications operating through a variety of services on a variety of 
different types of identity-specific data structures that are organized in accordance 
with a set or rules. Each service is configured to perform operations on one or more 
different types of data structures. For example, an identity may have an in-box data 
structure organized in accordance with an in-box schema and that is managed by an 

25 in-box service, a calendar data structure organized in accordance with a calendar 
schema and that is managed by a calendar service, and so forth. 
[0007] The principles of the present invention allow for authorization of a 
requesting entity to occur largely, if not wholly, independent of the type of the 
underlying data structure that is desired to be operated upon. This allows for a 

30 centralized authorization station that performs the entire authorization process for a 
wide variety of different services. The centralized authorization station may then 
inform the target service that the requested operation is authorized and provide the 
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service with sufficient information to perform the desired operation on the target data 
structure. Although only one authorization station is described and illustrated for 
clarity, there may more than one (and even numerous) authorization stations that 
perform the described authorization on behalf of the services. 
5 [0008] In one embodiment, the authorization state maintains a number of role 
templates that each define basic access permissions with respect a number of 
command methods. These role templates may be included within a role map 
document in which all of the role templates corresponding to a particular service are 
compiled. The role templates represent coarse-grained access permissions 

10 corresponding to permissions that might be of particular use when accessing the 
particular service. Thus, applications that are not able to implement more fine- 
grained access control may at least implement these core role templates for coarser- 
grained control over access permissions. When the authorization station receives a 
request, it identifies the target service and thereby accesses the appropriate role map 

1 5 that contains the corresponding role templates. 

[0009J The authorization station also maintains a number of role definitions that 
each define access permissions for specific requesting entities by using one or more of 
the role templates. In one embodiment, all of the role definitions that might define 
access permissions with respect to a particular identity's data are included within a 

20 role list document. There may be a role list document corresponding to a particular 
identity. Each role definition defines access privileges with respect to this identity's 
data for a requesting entity. The requesting entity is specified by a user identifier, an 
application-platform combination identifier, and a credential type identifier. 
[0010J The request specifies the identity whose data is desired to be operated 

25 upon, as well as the type of document that is desired to be accessed (e.g., content, role 
list, system). Based on this, the authorization station may identify the appropriate role 
list. The authorization station selects the appropriate role definition within the role 
list -using the user identifier, the application identifier, and the platform identifier " 
specified in the request. Also, the type of credentials used to authenticate are also 

30 used to identify the appropriate role definition. Thus, one authenticating using a more 
secure authentication mechanism may be granted more extensive access than the same 
user with the same application but using a less secure authentication mechanism. 
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[0011] When the authorization station receives a request from the requesting 
entity to perform at least one of the command methods, the authorization station then 
identifies the appropriate role definition. Using this role definition, the authorization 
station determines access permissions for the requesting entity with respect to the 
5 requested action. 

[0012] The present invention has the advantage of performing authorization in a 
standardized manner regardless of the target service that is desired. The service is 
only factored in when selecting an appropriate role map. In addition, this is 
accomplished while providing a standardized set of templates that may be used for 

10 coarse-grained control over access. Thus, applications that are not able to add further 
refined scopes to the role list may at least have some level of access control over the 
service's data structures. In addition, those that can define more refined scopes may 
have those more refined scopes included in the role list documents to allow for more 
user-specific and refined control over access permissions. These refined scopes may 

1 5 be included in the role list corresponding to the identity whose data is being accessed. 
Accordingly, the present invention provides for a high level of control over access 
permissions in a manner that is relatively independent of the underlying service being 
targeted. 

[0013] Additional features and advantages of the invention will be set forth in the 
20 description which follows, and in part will be obvious from the description, or may be 
learned by the practice of the invention. The features and advantages of the invention 
may be realized and obtained by means of the instruments and combinations 
particularly pointed out in the appended claims. These and other features of the 
present invention will become more fully apparent from the following description and 
25 appended claims, or may be learned by the practice of the invention as set forth 
hereinafter. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0014] In order to describe -the -manner in which- the above-recited and other- 
advantages and features of the invention can be obtained, a more particular 
30 description of the invention briefly described above will be rendered by reference to 
specific embodiments thereof which are illustrated in the appended drawings. 
Understanding that these drawings depict only typical embodiments of the invention 
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and are not therefore to be considered to be limiting of its scope, the invention will be 
described and explained with additional specificity and detail through the use of the 
accompanying drawings in which: 

[0015] Figure 1 schematically illustrates a general network environment in which 
5 the present invention may be employed; 

[0016] Figure 2 illustrates a specific example of a network environment in which 
the present invention may be employed; 

[0017] Figure 3 illustrates data structures including a role list data structure linked 
by reference with a role map data structure, the data structures being used to authorize 
1 0 a requestor to perform certain actions on identified data structures; 

[0018] Figure 4 illustrates a flowchart of a method for authorizing a requestor to 
perform certain actions on the identified data structure; and 

[0019] Figure 5 schematically illustrates a computing device that may implement 
the features of the present invention. 

15 DETAILED DESCRIPTION OF THE INVENTION 

[0020] The present invention extends to methods, systems and computer products 
for authorizing a requesting entity in a manner that is at least partially independent of 
the underlying target data structure that is desired to be accessed. In one operating 
environment, there are a number of individuals and applications operating through a 

20 variety of services on a variety of different types of identity-specific data structures 
that are organized in accordance with a set or rules. Each service is configured to 
perform operations on one or more different types of data structures. For example, an 
identity may have an in-box data structure organized in accordance with an in-box 
schema and that is managed by an in-box service, a calendar data structure organized 

25 in accordance with a calendar schema and that is managed by a calendar service, and 
so forth. 

[0021] The principles of the present invention allow for authorization of a 
requesting- entity to-occur- largely, if -not -wholly,- independent of- the type of the — 

underlying data structure that is desired to be operated upon. This allows for a 
30 centralized authorization station that performs the entire authorization process for a 

wide variety of different services. The centralized authorization station may then 

inform the target service that the requested operation is authorized and provide the 
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service with sufficient information to perform the desired operation on the target data 
structure. 

[0022] Embodiments within the scope of the present invention may comprise a 
special purpose or general purpose computing device including various computer 
5 hardware, as discussed in greater detail below. Embodiments within the scope of the 
present invention also include computer-readable media for carrying or having 
computer-executable instructions or data structures stored thereon. Such computer- 
readable media can be any available media which can be accessed by a general 
purpose or special purpose computer. By way of example, and not limitation, such 

10 computer-readable media can comprise physical storage media such as RAM, ROM, 
EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other 
magnetic storage devices, or any other medium which can be used to carry or store 
desired program code means in the form of computer-executable instructions or data 
structures and which can be accessed by a general purpose or special purpose 

1 5 computer. 

[0023] When information is transferred or provided over a network or another 
communications connection (either hardwired, wireless, or a combination of 
hardwired or wireless) to a computer, the computer properly views the connection as a 
computer-readable medium. Thus, any such connection is properly termed a 

20 computer-readable medium. Combinations of the above should also be included 
within the scope of computer-readable media. Computer-executable instructions 
comprise, for example, instructions and data which cause a general purpose computer, 
special purpose computer, or special purpose processing device to perform a certain 
function or group of functions. 

25 [0024] Although not required, the invention will be described in the general 
context of computer-executable instructions, such as program modules, being 
executed by computing devices. Generally, program modules include routines, 
programs, objects, components,- data structures, and the like that perform particular- 
tasks or implement particular abstract data types. Computer-executable instructions, 

30 associated data structures, and program modules represent examples of the program 
code means for executing steps of the methods disclosed herein. The particular 
sequences of such executable instructions or associated data structures represent 
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examples of corresponding acts for implementing the functions described in such 
steps. 

[0025] Those skilled in the art will appreciate that the invention may be practiced 
in network computing environments with many types of computer system 
5 configurations, including personal computers, hand-held devices, multi-processor 
systems, microprocessor-based or programmable consumer electronics, network PCs, 
minicomputers, mainframe computers, and the like. The invention may also be 
practiced in distributed computing environments where tasks are performed by local 
and remote processing devices that are linked (either by hardwired links, wireless 
10 links, or by a combination of hardwired or wireless links) through a communications 
network. In a distributed computing environment, program modules may be located 
in both local and remote memory storage devices. 

[0026] Figure 1 illustrates an example network environment 100 in which the 
present invention may be employed. The environment includes a variety of 

15 applications 110 (including applications 1 1 1 through 115) that interact with a variety 
of services 120 (including services 121 through 124) through an authorization station 
130. The applications 111 through 115 may be different types of applications as 
represented by each being illustrated as a different shape. There are a number of users 
140 associated with the applications 110. Specifically, users 141 through 145 are 

20 associated with applications 1 1 1 through 115, respectively. In this description and in 
the claims, a "requesting entity" may be a user, an application, a user-application 
combination, or any of these items in combination with a credential type representing 
a method of authentication. 

[0027] The services 120 may manage identity-specific information. For example, 
25 service 121 may be an in-box service that manages a number of in-box data structures 
121a through 121c that follow an in-box schema as represented by the data structures 
being squares. Each data structure may belong to a particular identity such as an 
individual, an organization, a group of individuals, a project, or any other identifiable 
entity. Through this description. Service 122 may be a calendar service that manages 
30 a number of calendar data structures 122a through 122c that follow a different, 
calendar schema as represented by each data structure being an octagon. Service 123 
may be a document service that manages various document data structures 123a 
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through 123c that follow a document schema as represented by each data structure 
being a half-circle. Service 124 may be a notification service that manages 
notification data structures 124a through 124c that follow a notification schema as 
represented by each data structure being a pentagon. 
5 [0028] This operating network is just one example of many possible network 
operating environments in which the present invention may be employed. For 
example, as represented by the ellipses in Figure 1, the number of applications 110 
and services 120 that interact with the authorization station 130 may vary. In 
addition, each service may manage more than just one different type of data structure. 

10 Furthermore, there is no requirement that the data being managed by the service be 
identity-specific although that is one specific implementation. Also, many of the 
services may employ additional authorization functionality not performed by the 
authorization station 130. Furthermore, although only one centralized authorization 
station is shown and described for clarity, there may more than one (and even 

1 5 numerous) authorization stations that perform the described authorization on behalf of 
the services. And finally, some of the functionality of the authorization station 130 
may also be employed instead by the services. 

[0029] In any case, the principles of the present invention allow for the 
authorization process to occur largely, if not wholly, independent of the type of data 
20 structure desired to be operated upon. Accordingly, a separate and distinct 
authorization station 130 may provide authorization for requests destined for a variety 
of different services. 

[0030] Figure 2 illustrates a more specific diagram of the authorization station and 
one of the services. The authorization station 130 receives a request from a 

25 requesting entity using a network protocol such as HyperText Transport Protocol 
(HTTP) represented by arrow 201, or Direct Internet Message Encapsulation (DIME) 
represented by arrow 202. The authorization station 130 includes a message 
connector 203, which receives the request and passes the message up the protocol - 
stack so that the request may be further processed. The request is then provided to an 

30 input thread pool 204 for temporary storage. 

[0031] The request is then parsed at a message processor 205, which parses the 
request into various components. For example, in one embodiment, the request is a 
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Simple Object Access Protocol (SOAP) message in which case the message processor 
205 parses using the appropriate SOAP protocol. The message processor 205 may 
also perform some preliminary level of rule checking to make sure the request should 
be further processed. For example, if the request is to manipulate a data structure that 
5 none of the services 120 manage, then the message processor 205 may abstain from 
passing the request further down the process flow, and instead simply generate an 
error message using the response generation module 212 to be returned via the 
message connector 203. 

[0032] The request may then be filtered by a firewall 206 and then logged using a 

10 logger 207. A firewall may also reject a request and generate an error message using 
the response generation module 212 that is returned as a response. A local log 210 
may receive and store event information received from the firewall 206, as well as 
normal logging information received from the logger 207 such as the following for 
each received request: time received, method type, attribute types, and address of 

1 5 request. Then, an authorization module 208 determines if the request is authorized to 
perform the requested operation on the target data structure. More detail regarding 
this authorization process will be described further below after the complete process 
flow has been described. If authorization fails, then an error message is returned via 
the response generation module 212 and the message connector 203. 

20 [0033] In one example, the request is in the form of a SOAP envelope, which 
contains unencrypted header information, as well as an optional encrypted body 
portion. A decryption module 209 decrypts the body of the request. Then, a signature 
checker 211 checks any signatures associated with the request to guard against 
tampering. Any failed decryption or signature checking may also be returned to the 

25 requestor in the form of an error message generated by the response generation 
module 212. 

[0034] After signature checking, the authorization station 130 then passes 
information sufficient to accomplish the requested operation to the appropriate target 
service. This information includes a message that the request is authorized, the scope 
30 of access permissions, an identification of the requested method, and any needed 
request details. 
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[0035] Suppose that the target service is the service 121 referred to in Figure 2. 
The information is passed to the service dispatch module 221 of the service 121. The 
service logic 222 then receives and processes the information. The service logic 222 
is capable of performing standard methods 223. An example a standard method set 
5 includes insert, query, update, delete, and replace as illustrated. The service logic 222 
may also include some service-specific methods 224. 

[0036] In order to execute the requested operation, the service logic accesses a 
data store that stores the data structures to be manipulated. In one embodiment, the 
data structures to be operated upon are extensible Markup Language (XML) 

10 documents in which case the data store is an XML data store 225. The data structures 
to be accessed may be content documents 226 that contain the actual content of 
primary interest to the application or user. As an example, such content documents 
may be any of the data structures listed in Figure 1 such as in-box, calendar, 
document, and notification data structures. 

15 [0037] The service may also manipulate role list documents 227. Role list 
documents 227 define access privileges to a specific identity's data given a particular 
role assigned to the requestor. The authorization module 208 of the authorization 
station communicates with the role list document 227 when authorizing the requesting 
entity. More regarding the role lists documents will be described in further detail 

20 below. The service may also manipulate system documents 228 that define system- 
related information. 

[0038] Once the requested operation is performed on the target data structure 
using the service logic 222 interacting with the XML store 225, response information 
is provided to service completion module 229. The response information is then 

25 passed to response generation module 212 for generation of an appropriate response. 
The response is then returned to the user via the message connector 203. 
[0039] Figure 3 illustrates a number of role lists 340 including role list documents 
. 340(1) through 340(4). Each role list is specific to a particular identity-who owns data 
structures stored by the service. Each identity may have content documents, role list 

30 documents, and system documents. The role list document governs access to each 
type of document (i.e., content, system, and even role list documents) for each 
identity. For the sake of discussion, suppose that the top role list controls access to 
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content documents belonging to Fred. Each role list includes a number of role 
definitions such as role definitions 350A, 350B, 350C and so forth, that each define 
access privileges for entities that may potentially request to operate on Fred's content 
data structures. 

5 [0040] The role definitions 350 define access privileges using role templates 310. 
Figure 3 illustrates three role templates 31 OA, 31 0B and 3 10C. In one example, the 
role definition uses the role templates by directly including the role template, or (as 
illustrated) by instead referring to the role template. 

[0041] Figure 4 illustrates a method 400 for authorizing a requesting entity to 
10 operate upon a data structure in a standard manner that is at least partially, if not 

wholly, independent of the type of underlying data structure being operated upon. 

The method 400 first includes an act of maintaining a number of role templates (act 

401) that each define basic access permissions with respect a number of command 

methods, wherein at least some of the role templates define access permissions in a 
15 manner that is independent of the type of data structure being accessed. In Figure 2, 

these role templates may be maintained in, for example, the role list documents 227 at 

the XML store 225. 

[0042] In order to understand how the role definitions define access privileges in 
one embodiment, this description will now describe scopes, role templates, role maps, 

20 and role definitions in that order with respect to a specific example. Scopes 320 (e.g., 
scopes 320A, 320B, and 320C) define general views on data using a standardized 
language. The following defines a schema or set of rules regarding how to structure a 
"scope" XML element in one embodiment. Throughout the following examples, an 
"hs" as in <hs: scope . . .> represents the namespace or schematic that may be used to 

25 interpret the corresponding element. A "namespace" may be, for example, a 
namespace as defined in the "Namespaces in XML" specification published by the 
World Wide Web Consortium (or "W3C"). 
<hs:scope id^'\.."> 

<hs:name xml:lang="... M dir= n ...">0..unbounded</hs:name> 

30 <hs:shape base='\.. M >l..l 

<hs:include select="...">0..unbounded</hs:include> 
<hs:exclude select-'.. .">0..unbounded</hs:exclude> 
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</hs:shape> 
</hs:scope> 

[0043] The "scope" element defines a scope, which may be referred by a role 
definition to indicate what portions of the document are visible to that role definition 
5 for a specified method. The "scope/@id" attribute of the "scope" element is a 
globally unique identifier that is assigned to identify the scope. The identifier may be 
assigned by the authorization station 130, or may be manually set or overridden by an 
application when the scope is generated. 

[0044] The "scope/name/@xml:lang" attribute is used to specify an ISO 639 
10 language code or an ISO 3166 country code as described in RFC 1766. ISO is short 
for "International Organization for Standardization". RFC is a "Request For 
Comment" that comprises a series of notes (usually Internet-based notes) about a 
certain topic. The value of this attribute indicates the language type of the content 
within this element. The "scope/name/@dir" optional attribute specifies the default 
15 layout direction for any localized string specified in any select attribute within the 
"scope" element (e.g., right to left, or left to right). Other elements also have these 
"@xml:lang" and "@dir" attributes for equivalent purposes. 

[0045] The "scope/shape" element defines the visible node set of the document 
when operating through this "scope" element. The "scope/shape/@base" attribute 

20 specifies the initial set of nodes visible through the shape. A value of "t" indicates that 
the shape is initialized to include all possible nodes relative to the shape that is 
currently in effect. In other words, when defining a shape for a role, the value "t" 
indicates all possible nodes are available in the specified document. The value "nil" 
indicates the empty node set. 

25 [0046] The "scope/shape/include" element specifies the set of nodes that should 
be included into the shape relative to the possible set of nodes indicated by the base 
attribute. The "scope/shape/include/@select" attribute specifies an XPATH 
expression that selects a set of nodes relative to the externally established context. 
"XPATH" is a standard published by the World Wide Web Consortium (or "W3C") 

30 and may be, for example, XML Path Language (XPATH) Version 1.0 or later. The 
"scope/shape/exclude" element specifies the set of nodes that should be excluded 
from the shape relative to the possible set of nodes indicated by the base attribute. 
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The "scope/shape/exclude/@select" attribute specifies an XPATH expression that 
selects the set of nodes to exclude. 

[0047] In order to better understand this schema, two examples of "scope" 
elements will now be listed and described. As a first example, consider the following 
5 "scope" XML element. 

<scope id="F> 

<shape base="f7> 
</scope> 

10 [0048] The first and third line of this XML element define the XML element as 
being a "scope". The attribute id="l" in the first line assigns the scope with an 
identifier "1". The second line defines a shape that may be used to define the scope. 
Here the base attribute of the shape is assigned a value of "t" indicating that the shape 
base starts with all nodes in the target data structure. Furthermore, since there are no 

1 5 "exclude" elements within the "shape" element, the shape remains the entire node set. 
This scope will thus be referred to as the "all data" scope. 
[0049] Now consider the following second example of a "scope" element. 
<scope id="2"> 

<shape base= f, nir> 

20 ^include select=7* [cat/@ref=*'public M ]/> 

</shape> 
</scope> 

[0050] The attribute id="2" in the first line assigns the scope with an identifier 
"2". The second line defines a shape with a base attribute assigned a value of "nil" 

25 indicating that the shape base starts with no nodes in the target data structure. The 
"include" element in the third line indicates that all nodes that satisfy the XPATH 
statement in its "select" attribute are to be added to the shape base to define the shape. 
In this case, the "include" element specifies that the shape includes all of the nodes - 
that have a "cat" element having a "ref ' attribute of value "public" (in other words, all 

30 public nodes) are to be included in the shape. Such scopes will thus be referred to as 
the "only public items" scope. The "cat" element provides for categorization of the 
element by whatever categorization is useful for the containing element. The "ref 
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attribute provides for a particular categorization value. Thus, scopes define a general 
view on data that is limited to public items. 

[0051] Referring to Figure 3, there are also role templates 310. The role 
templates 310 define general access permissions for each method (e.g., for each 
5 standard method 223 and/or each service specific method 224). In one embodiment, 
the role templates are XML documents that follow the following schema: 
<hs:roleTemplate name= M ..." priority-'. .. H >0..unbounded 

<hs:ftillDescription xml:lang="..." dir= ,, ...">0..1</hs:fullDescription> 
<hs:method name-'..." scopeRef= f, ...">0.,unbounded</hs:method> 

1 0 </hs:roleTemplate> 

[0052] This "roleTemplate" element defines the maximum scope of information, 
and the allowable methods used to access that information for each request mapped 
into the template. The "roleTempIate/@name" attribute specifies the name of the role 
template. The "roleTemplate/@priority" attribute specifies the priority of the role 

15 template should multiple role templates apply to a particular requesting entity, thus 
facilitating selection of a single role template. The "roIeTemplate/fullDescription" 
element contains a description of this role template which specifies the capabilities a 
caller will have when accessing information through this role template. 
[0053] The "roleTemplate" element may include multiple "method" elements. 

20 Each "method" element specifies access privileges available when using a specific 
method. When a requesting entity maps to a role template, the method in the request 
must match one of these elements for the message to continue to flow. If the method 
exists, the data available to the method is a function of the scope referenced by this 
method combined with an optional scope referenced by the role definition included in 

25 the role list. The combining of the method scope with the optional scope will be 
explained in further detail below. 

[0054] The "roleTemplate/method/@name" attribute specifies the name of the 
method. The "roleTemplate/method/@scopeRef specifies the scope that is in effect 
for this method. The scope referred within the method element is in the same role 
30 map as the role template that contains the method element. 

[0055] Four examples of "roleTemplate" XML documents will now listed and 
described. Consider the first example as follows: 
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<roleTemplate name="rt0"> 

<method name="query" scopeRef= M 1 M A> 

<method name-'insert" scopeRef='i M /> 

<method name-'replace" scopeRef='T7> 
5 <method name- 'delete" scopeRe£=" 1 7> 

<method name="update" scopeRef=" 1 7> 
</roleTemplate> 

[0056] This role template is assigned a name "rtO". In this example role template, 
five "method" elements are listed, one for each of the standard methods 223. Each of 
10 these methods is assigned the scope with an identifier of "1", which was the "all data" 
scope. Accordingly, this role template allows full access for all of the standard 
methods. Accordingly, this role template will often be referred to as the "full access" 
role template. 

[0057] Consider the following second example of a role template: 
1 5 <roleTemplate name="rt 1 "> 

<method name= tf query" scopeRef='T'/> 
</roleTemplate> 

[0058] This role template is assigned a name "rtl". In this example role template, 
there is only one "method" element, which references the "query" method. The "all 
20 data" scope having the identifier "1" is assigned to this method. Accordingly, the role 
template facilitates querying of all the data, but no other operations on any data. 
Accordingly, this role template will also be referred to as the "full read-only" role 
template. 

[0059] Consider the following third example of a role template: 
25 <roleTemplate name="rt2"> 

<method name="query" scopeRef= n 2 n /> 
</roleTemplate> 

40060] This role template is assigned a name "rt2". In this example role template, 
there is again only one "method" element, the "query" method. The "only public 
30 items" scope having the identifier "2" is assigned to this method. Accordingly, the 
role template facilitates only the querying of only public items. Accordingly, this role 
template will be referred to as the "limited read-only" role template. 
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[0061] Consider the fourth and final example of a role template: 
<roleTemplate name="rt99"/> 

[0062] This role template is assigned a name "rt99". In this example role 
template, there are no "method" elements. Accordingly, the role template does not 
5 facilitate any operations on any data at all. Accordingly, this role template will be 
referred to as the "no access" role template. 

[0063] Referring to Figure 3, note that the scopes 320 and the role templates 310 
are included within a single role map 330(1). In an example, the role maps 330 
include several role maps, one for each service. For example, the role map 330(1) 
10 corresponds to an in-box service, the role map 330(2) corresponds to a calendar 
service, the role map 330(3) corresponds to a document service, and the role map 
330(4) corresponds to the notification service. 

[0064] In accordance with the example, the role maps follows the following 
schema: 

15 <hs:roleMap changeNumber= M ..." id="... M creator="... M xmlns:hs="http://.... M >l..l 
{Scope} "... M >0..unbounded 
{Role Template}>0..unbounded 
</hs:roleMap> 

[0065] As illustrated in Figure 3 and as listed in the above schema, a role map 
20 may contain any number of scopes and role templates. Any bracketed items represent 
structures that have been previously described. For example, the "{Scope}" item 
listed in the above example represents a scope element that follows the scope schema 
described above. Thus, "{Scope} M ... n >0..unbounded" represents that there may be 
any number of such scope elements inserted at that part of the role map. Similarly, 
25 "{Role Template } "..."^..unbounded" represents that there may be any number of 
role template elements inserted at that part of the role map, the role templates being 
data structures that follow the role template schema described above. 
[0066] . The "roleMap/@changeNumber" attribute- facilitates caching of the 
element and its descendants. The "roleMap/@id" attribute is a globally unique 
30 identifier assigned to this element. Application software may also override this 
identifier generation by specifying such in the request message. The 
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"/roleMap/@creator" attribute identifies the creator in terms of a user identifier, an 
application identifier, and a platform identifier of the role map. 
[0067] The following is an example of an XML role map that includes the two 
example scopes and the four example role templates listed above. 
5 <roleMap> 

<!--all data scope~> 
<scope id="P> 

<shape base="t7> 
</scope> 



10 



<!-only public items scope~> 
<scope id="2"> 



<shape base= M niP> 



<include select=7* [cat/@ref= M public M ]/> 



15 



</shape> 
</scope> 



<!-- full access— > 



<roleTemplate name= M rt0 M > 



20 



<method name="query" scopeRef=" 1 "f> 
<method name-' insert" scopeRef='T'/> 
<method name="replace" scopeRef=" 1 "/> 
<method name="delete" scopeRe£=" 1 "f> 
<method name="update" scopeRef= M l"/> 



25 



<roleTemplate> 



<! — full read-only (query method)--> 
<roleTemplate name="rt 1 "> 



30 



<method name="query M scopeRef=" 1 "/> 
</roleTemplate> 



<!-- limited read-only — > 
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<roleTemplate name- 'rt2 rt > 

<method name="query M scopeRef="2"/> 
</roleTemplate> 

5 <!— no access--> 

<roleTemplate name="rt997> 

</roleMap> 

[0068J In summary, the role map defines general access permissions using role 
10 templates that refer to scopes. In one embodiment, role templates are generated that 
are representative of typical access permissions that might be desired by users using 
the particular service. Referring to Figure 4, the authorization station maintains these 
role templates and thus accomplishes the act of maintaining a number of role 
templates (act 401) that each define basic access permissions with respect a number of 
15 command methods, wherein at least some of the role templates define access 
permissions in a manner that is independent of the type of data structure being 
accessed. Note that the target service is only factored in when selecting a role map to 
use. The process then remains the same regardless of the target service. 
(0069) The method 400 then includes a step for authorizing a requesting entity 
20 using the role templates in a manner that is independent of the type of data structure 
being accessed (step 402). This may include any corresponding acts for 
accomplishing this functional purpose. However, in the example of Figure 4, this 
includes corresponding acts 403, 404, 405 and 406. 

[0070] For example, the method 400 includes an act of maintaining a number of 
25 role definitions (act 403) that each define access permissions for specific entities by 
using one or more of the role templates. While the role definitions may take any 
form; in one example, the role definition takes the form of a "role*' XML element that 

is contained within a "role list" element.- In this-example,-each of-the role lists-340 - 

(e.g., role lists 340(1) through 340(4)) applies to a specific identity and to a specific 
30 type of document (e.g., content). For example, the role list 340(1) may apply to 
Fred's content data, role list 340(2) may apply to Sam's role list data, role list 340(3) 
may apply to Diane's system data, and role list 340(4) may apply to Fred's role list 
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data. Referring to the role list 340(1), the role list includes a number of refined scopes 
360 including refined scopes 360A, 360B and 360C. The role list 340(1) also 
includes several role definitions 350A, 350B and 350C. 
[0071] The following is an example schema for a role list. 
5 <hs:roleList changeNumber= M ..." instanceId= u ... M xmlns:hs= H http://... H >l..l 
{ scope }>0. .unbounded 

<hs:role scopeRe£="... M roleTemplateRef="..." changeNumber='\.." id-"..." 
creator^" . . . ">0. .unbounded 
<hs :cat ref= M . . . ">0 . .unbounded</hs :cat> 
10 <hs:notes xml:lang= n ..." dir="... M >0..unbounded</hs:notes> 

<hs:subject userld="..." credType="... M 

appAndPlatformId= ,l ... M > 1 .. l</hs:subject> 
<hs:expiresAt>0.. 1 </hs:expiresAt> 
{any} 

15 </hs:role> 
</hs:roleList> 

[0072] The "role list" contains a number of scopes that allow for more fine- 
grained defining of scopes. The scopes may follow the same scope schema that was 
described further above. The role list also include any number of role definitions in 
20 the form of "role" elements. The various elements and attributes will now be 
described. 

[0073] The "roleList/@changeNumber" attribute facilitates caching of the 
element and its descendants. The "roleList/@instanceId" attribute a unique identifier 
typically assigned to the root element of a service. The "rolelist/role" is a role 

25 definition that matches a particular requesting entity with particular access rights. 
These access rights are defined by any applicable scope referred to in any applicable 
role template, along with any scope directly referred to in the role definition itself. 
. [0074] The "roleList/role/@scopeRef ' attribute specifies the scope in the role list 
that is in effect for this role definition. The "roleList/role/@roleTemplateRer 

30 attribute specifies the name of the role template in the service's role map that this role 
definition is bound to. The "roleList/role/@changeNumber attribute is designed to 
facilitate caching of the element and its descendants. The /roleList/role/@id" attribute 
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is a globally unique ID assigned to this element. The "roleList/role/@creator" 
attribute identifies the creator in terms of user identifier, application identifier, and 
platform identifier. The "roleList/role/cat" categorizes the element that contains it by 
referencing a global category. The "roleList/role/notes" specifies notes that may be 
5 used to specify reasoning behind adding this role to the roleList. 

[0075] The "roleList/role/subject" element identifies the requesting entity to 
whom the role definition is to apply. The requesting entity may be defined by a user 
identifier, an application identifier, and a platform identifier, each represented by 
attributes within the "subject" element. The role definition may also be dependent on 
10 the credential types provided by the request. Hence, the presence of the credType 
attribute within the "roleList/role/subject" element. 

[0076] Specifically, the u roleList/role/subject/@userId" attribute specifies an 
authenticated user identifier. The "roleList/role/subject/@credType" attribute 
specifies a credential type value that represents the type of credential used to 
15 authenticate the user identifier. The "roleList/role/subject/@appAndPlatformId" 
attribute specifies the authenticated identifier of an application-platform combination. 
These attributes combine to define a requesting entity. 

[0077] The "roleList/role/expiresAt" element specifies a time after which the 
requesting entry is no longer considered valid for matching purposes. The 
20 "/roleList/role/{any}" portion allows for the role list schema to be extended at that 
location. 

[0078] Referring to Figure 4, by maintaining these role definitions in the form of a 
role list, the authorization station 130 may accomplish the act of maintaining a 
number of role definitions (act 403). For the sake of clarity, a specific example of an 
25 XML role list that follows the above described "role list" schema is now listed and 
will be described. 
<roleList> 

<!~only golf related stuff--> 
30 <scopeid= H r> 

<shape base- 'nir> 

include select=7* [cat/@ref= M golf ']/> 
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</shape> 
</scope> 

<role roleTemplateRef="rtO"> 
5 <subject userId= n puid-of:fred" appAndPlatformId="puid- 

of:calendar@contoso.com"/> 

</role> 

<role roleTemplateRef= M rtr> 
1 0 <subject userId="puid-of:fred" appAndPlatformId= M puid- 

of:calendar@fabrikam.com"/> 

</role> 

<role scopeRef="l M roleTemplateRef="rt2 M > 
1 5 <subject userId= M puid-of:barry M /> 

</role> 

<role roleTemplateRef="rt99"> 

<subject userId="ALLJLJSERS" appAndPlatformId="puid- 

20 of:app@cpandl.com M /> 
</role> 
</roleList> 

[0079J This role list includes one refined "scope" element and four "role" 
elements. The first "role" element means: fred running calendar@contoso.com can 

25 access all information, through all methods. Recall that role template "rtO" allows 
access to all information through all methods. The second "role" element means: fred 
running calendar@fabrikam.com only has read-only access to all information. The 
third "role" element means: barry running any application has read-only access to 
only public information, but only those pieces of public information that are 

30 categorized as golf related. This last access stipulation represents a refinement that 
was added to this role list to allow for more fine-grained control over access 
privileges. It is accomplished by reference to the local refined scope listed at the 
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beginning of the role list. The last "role" element means: any and all users running 
the app@cpandl.com application have no access to any information held within this 
service. 

[0080] The method 400 then includes an act of receiving a request from the 
5 requesting entity to perform at least one of the command methods, the request 
identifying the requesting entity (act 404). In one embodiment, the request identifies, 
at least in encrypted form, the user identifier, the application identifier, the platform 
identifier, and the credential type identifier. 

[0081] The method 400 then includes an act of identifying a role definition 

10 corresponding to the requesting entity (act 405). First, the appropriate role list is 
identified by identifying the owner and type (e.g., content, role list, system) of the 
target data structure. Then, the user identifier, application identifier, platform 
identifier, and credential type identifier received in the request is matched against 
those similar fields in the "subject" element of the role definition. This may be 

1 5 accomplished via a database lookup. 

[0082] The matching process may be as follows. In a first matching operation, 
the user identifier in the message is matched against "userld" attributes in the 
"subject" element of the role definitions to find a first set of matching role definitions. 
Once this first set of matching role definitions is identified, a second match operation 

20 is performed. In this second matching operation, the credential type identifier 
associated with the request is matched with the "credType" attribute in the "subject" 
element of the first set of role definitions to narrow to a second set of matching role 
definitions. If there are no role definitions in the second set of role definitions, then 
all role definitions from the first set having a "subject" elements containing the 

25 "credType" attribute are discarded keeping only those "subject" elements that do not 
contain a "credType" attribute to form the second set of role definitions. 
[0083] Then, a third matching operation is performed in which the combined 
platform identifier and application identifier of the request are matched against the 
"appAndPlatformld" attribute of the second set of role definitions. This generates a 

30 third set of role definitions. If there are no role definitions in the third set of role 
definitions, then all role definitions from the second set having a "subject" elements 
containing the "appAndPlatformld" attribute are discarded keeping only those 
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"subject" elements that do not contain an "appAndPlatformld" attribute to form the 
third set of role definitions. If a matching role element is not found, the request is 
failed with an authorization fault. Also, if the matching role definition contains an 
"expiresAt/" element that indicate that the role definition has expired, then an error 
5 message is also returned. 

[0084] Note that the role list structure allows for different role definitions even for 
the same user and the same application should the user authenticate using different 
authentication methods and thus create different credential type identifiers. Thus, a 
user authenticating using a more secure authentication mechanism may be granted 
10 more extensive access than the same user using a less secure authentication 
mechanism. 

[0085] The role list lookup may be further optimized through the use of licenses. 
When an application sends a message containing an identity license, the authorization 
station 130 finds a role template and a refined, local scope corresponding to the 

15 request as described above. The authorization station 130 then places this in the 
request as an "authorized role". Once the request has been fulfilled, the authorization 
station 130 sends a response back which includes an <authorizedRole/> element. 
When the application sends a subsequent request back to the same service, the request 
includes both the identity license and the authorized role license. During 

20 authorization, the authorization station 130 notices the authorized role license, and 
determines that it is valid and that it was properly issued to the identity sending the 
message. The authorization station 130 then uses the information contained within 
the authorized role element (i.e., the appropriate role template with the refined, local 
scope), instead of once again accessing the role list database. Thus, a database lookup 

25 process is avoided for subsequent accesses to the same service. 

[0086] The method 400 includes an act of determining access permissions for the 
requesting entity with respect to the command method using the role definition 
corresponding to the requesting entity (act 406). In order to accomplish this, the role - 
templates in the service's role map are extracted and only the highest priority role 

30 template is kept. The specified command method is compared with the applicable 
role template to determine if the method is allowed. If it is not allowed, then an error 
message is returned. If the method is allowed, then the scope corresponding to that 
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method (as referred to in the role template) is combined with any refined scope 
referenced by the role definition found within the role list. This information is then 
passed to the target service along with an authorization to proceed. 
[0087] The present invention has the advantage of performing authorization in a 
5 standardized manner regardless of the target service that is desired. The service is 
only factored in when selecting an appropriate role map. 

[0088] In addition, this is accomplished while providing a standardized set of 
templates that may be used for coarse grained control over access. Thus, applications 
that are not able to add further refined scopes to the role list may at least have some 

10 level of access control over the service's data structures. Furthermore, those 
applications that can define more refined scopes may have those more refined scopes 
included in the role list documents to allow for more user-specific and refined control 
over access permissions. Accordingly, the present invention provides for a high level 
of control over access permissions in a manner that is relatively independent of the 

1 5 underlying service being targeted. 

[0089] As a final advantage, note that scopes define views on a document. Thus, 
unlike conventional access control lists, the present invention facilitates access 
granularities below the document level. In other words, portions of documents may 
be viewed or operated upon, while other portions remain secure. 

20 [0090] Having now described the principles of the present invention in detail, it is 
noted that the precise hardware configuration that implements the above-described 
features is not important to the present invention. For example, it is not important to 
the principles of the present invention where the authorization station 1 30 or services 
120 are implemented. 

25 [0091] Nevertheless, for the sake of completeness, Figure 5 illustrates an example 
computing system that may itself or in combination with other computing devices 
implement all or portions of the features described above. The example system 
includes a general purpose computing device in the form of a conventional computing 
device 520, including a processing unit 521, a system memory 522, and a system bus 

30 523 that couples various system components including the system memory 522 to the 
processing unit 521. The system bus 523 may be any of several types of bus 
structures including a memory bus or memory controller, a peripheral bus, and a local 
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bus using any of a variety of bus architectures. The system memory includes read 
only memory (ROM) 524 and random access memory (RAM) 525. A basic 
input/output system (BIOS) 526, containing the basic routines that help transfer 
information between elements within the computer 520, such as during start-up, may 
5 be stored in ROM 524. 

[0092] The computer 520 may also include a magnetic hard disk drive 527 for 
reading from and writing to a magnetic hard disk 539, a magnetic disk drive 528 for 
reading from or writing to a removable magnetic disk 529, and an optical disk drive 
530 for reading from or writing to removable optical disk 531 such as a CD-ROM or 

10 other optical media. The magnetic hard disk drive 527, magnetic disk drive 528, and 
optical disk drive 530 are connected to the system bus 523 by a hard disk drive 
interface 532, a magnetic disk drive-interface 533, and an optical drive interface 534, 
respectively. The drives and their associated computer-readable media provide 
nonvolatile storage of computer-executable instructions, data structures, program 

15 modules and other data for the computer 520. Although the exemplary environment 
described herein employs a magnetic hard disk 539, a removable magnetic disk 529 
and a removable optical disk 531, other types of computer readable media for storing 
data can be used, including magnetic cassettes, flash memory cards, digital versatile 
disks, Bernoulli cartridges, RAMs, ROMs, and the like. 

20 [0093] Program code means comprising one or more program modules may be 
stored on the hard disk 539, magnetic disk 529, optical disk 531, ROM 524 or RAM 
525, including an operating system 535, one or more application programs 536, other 
program modules 537, and program data 538. 

[0094] A user may enter commands and information into the computer 520 
25 through keyboard 540, pointing device 542, or other input devices (not shown), such 
as a microphone, joy stick, game pad, satellite dish, scanner, or the like. These and 
other input devices are often connected to the processing unit 521 through a serial port 

interface 546 coupled to system bus 523. -Alternatively, the input devices may be 

connected by other interfaces, such as a parallel port, a game port or a universal serial 
30 bus (USB). A monitor 547 or another display device is also connected to system bus 
523 via an interface, such as video adapter 548. In addition to the monitor, personal 
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computers typically include other peripheral output devices (not shown), such as 
speakers and printers. 

[0095] The computer 520 may operate in a networked environment using logical 
connections to one or more remote computers, such as remote computers 549a and 
5 549b. Remote computers 549a and 549b may each be another personal computer, a 
server, a router, a network PC, a peer device or other common network node, and 
typically include many or all of the elements described above relative to the computer 
520, although only memory storage devices 550a and 550b and their associated 
application programs 536a and 536b have been illustrated in Figure 5. The logical 
10 connections depicted in Figure 5 include a local area network (LAN) 551 and a wide 
area network (WAN) 552 that are presented here by way of example and not 
limitation. Such networking environments are commonplace in office-wide or 
enterprise-wide computer networks, intranets and the Internet. 

[0096] When used in a LAN networking environment, the computer 520 is 
1 5 connected to the local network 551 through a network interface or adapter 553. When 
used in a WAN networking environment, the computer 520 may include a modem 
554, a wireless link, or other means for establishing communications over the wide 
area network 552, such as the Internet. The modem 554, which may be internal or 
external, is connected to the system bus 523 via the serial port interface 546. In a 
20 networked environment, program modules depicted relative to the computer 520, or 
portions thereof, may be stored in the remote memory storage device. It will be 
appreciated that the network connections shown are exemplary and other means of 
establishing communications over wide area network 552 may be used. 
[0097] Accordingly, the principles of the present invention allow for authorization 
25 of requesting entities in a manner that is largely independent of the underlying service 
being targeted. Accordingly, the authorization process may be performed as a 
centralized function while the services are left without having to perform significant 
authorization processes. — 

[0098] The present invention may be embodied in other specific forms without 
30 departing from its spirit or essential characteristics. The described embodiments are 
to be considered in all respects only as illustrative and not restrictive. The scope of 
the invention is, therefore, indicated by the appended claims rather than by the 
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foregoing description. All changes which come within the meaning and range of 
equivalency of the claims are to be embraced within their scope. 
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1 . In a computer network that includes different types of data structures, a 
method for authorizing a requesting entity to operate upon data structures in a 
standard manner, the method comprising: 

an act of maintaining a plurality of role templates that define basic access 
5 permissions with respect to one or more command methods, wherein at least some of 
the role templates define access permissions in a manner that is independent of the 
type of data structure being accessed; 

an act of maintaining a plurality of role definitions that define access 
permissions for specific entities by using one or more of the role templates; 
10 an act of receiving a request from the requesting entity to perform at least one 

of the command methods, the request identifying the requesting entity; 

an act of identifying a role definition corresponding to the requesting entity; 

and 

an act of determining access permissions for the requesting entity with respect 
15 to the command method using the role definition corresponding to the requesting 
entity. 

2. A method in accordance with Claim 1, wherein the act of maintaining 
a plurality of role definitions that define access permissions for specific entities 
comprises: 

20 an act of the role definition corresponding to the requesting entity using at 

least one access permission that is specific to the requesting entity, wherein the access 
permission for the requesting entity are defined by the one or more role templates that 
are used by the corresponding role definition as well as the access permission that is 
specific to the requesting entity. 

25 3. A method in accordance with Claim 1, wherein the request includes an 

identification of credentials used to authenticate the requesting entity, wherein the role 
definition corresponding to the requesting entity is identified using the credential 
identification, wherein different role definitions may apply depending on the 
credentials. 

30 4. A method in accordance with Claim 1 , wherein the request identifies 

the requesting entity by identifying a user as well as a corresponding application that 
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is making the request, wherein different role definitions may apply depending on both 
the identification of the user as well as the corresponding application. 

5. A method in accordance with Claim 1, wherein the act of maintaining 
a plurality of role templates that define basic access permissions comprises the 

5 following: 

an act of maintaining a role map document that contains all of the role 
templates for a particular service. 

6. A method in accordance with Claim 5, wherein the act of maintaining 
a role map document that contains all of the role templates for a particular service 

1 0 comprises the following: 

an act of defining one or more scopes that describe views on a data structure; 

and 

an act of defining a role template by associating a method type with one of the 
one or more scopes. 

15 7. A method in accordance with Claim 5, wherein the act of maintaining 

a role map document that contains all of the role templates for a particular service 
comprises the following: 

an act of maintaining a role map document as a hierarchical data structure. 

8. A method in accordance with Claim 5, wherein the act of maintaining 
20 a role map document that contains all of the role templates for a particular service 

comprises the following: 

an act of maintaining a role map document as an XML document. 

9. A method in accordance with Claim 1, wherein the act of maintaining 
a plurality of role definitions that define access permissions for specific entities by 

25 using one or more of the role templates comprises the following: 

an act of maintaining a role list document that contains all of the role 
definitions for requesting entities that may attempt to access data structures belonging 
to an identity. 

10. A method in accordance with Claim 9, wherein the act of maintaining 
30 a role list document comprises the following: 

an act of defining a role definition by referencing a role template included in a 
role map document. 
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11. A method in accordance with Claim 10, wherein the act of maintaining 
a role list document comprises the following: 

an act of maintaining a role list document as a hierarchical data structure. 

12. A method in accordance with Claim 10, wherein the act of maintaining 
5 a role list document comprises the following: 

an act of maintaining a role list document as an XML document. 

13. A method in accordance with claim 1, wherein the act of receiving a 
request from the requesting entity to perform at least one of the command methods 
comprises the following: 

10 an act of receiving a request from the requesting entity to insert a portion into 

the data structure. 

14. A method in accordance with claim 1, wherein the act of receiving a 
request from the requesting entity to perform at least one of the command methods 
comprises the following: 

15 an act of receiving a request from the requesting entity to delete a portion from 

the data structure. 

15. A method in accordance with claim 1, wherein the act of receiving a 
request from the requesting entity to perform at least one of the command methods 
comprises the following: 

20 an act of receiving a request from the requesting entity to update a portion of 

the data structure. 

16. A method in accordance with claim 1, wherein the act of receiving a 
request from the requesting entity to perform at least one of the command methods 
comprises the following: 

25 an act of receiving a request from the requesting entity to replace a portion of 

the data structure. 

17. A method in accordance with claim 1, wherein the act of receiving a 
request from the requesting entity to perform at least one of the command methods 
comprises the following: 

30 an act of receiving a request from the requesting entity to query regarding a 

portion of the data structure. 
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18. A method as recited in Claim 1, wherein the one or more command 
methods comprise a set including insert, delete, query, update, and replace. 

19. A method as recited in Claim 1, wherein the data structure represents 
in-box information. 

5 20. A method as recited in Claim 1, wherein the data structure represents 

calendar information. 

21. A method as recited in Claim 1, wherein the data structure represents 
document information. 

22. A method as recited in Claim 1, wherein the data structure represents 
10 notification information. 

23. A method as recited in Claim 1, wherein the data structure represents 
content information. 

24. A method as recited in Claim 1 , wherein the data structure represents 
role list information, 

15 25. A method as recited in Claim 1, wherein the data structure represents 

system information. 

26. A method as recited in Claim 1 , wherein the act of identifying a role 
definition corresponding to the requesting entity comprises: 

an act of identifying the role definition by searching a database. 
20 27. A method as recited in Claim 1 , wherein the act of identifying a role 

definition corresponding to the requesting entity comprises: 

an act of identifying the role definition based on authorized role information 
provided within the request. 

28. A method as recited in Claim 27, wherein the authorized role 
25 information includes an identification of a role template. 

29. A method as recited in Claim 28, wherein the authorized role 
information further includes an identification of at least one refined, local scope. 

— 30. A computer-readable medium - comprising computer-executable 
instructions for performing the acts recited in Claim 1 . 
30 31. In a computer network that includes different types of data structures, a 

method for authorizing a requesting entity to operate upon data structures in a 
standard manner, the method comprising: 



WO 02/073392 



PCT/US02/06245 



32 

an act of maintaining a number of role templates that define basic access 
permissions with respect to a number of command methods, wherein at least some of 
the role templates define access permissions in a manner that is independent of the 
type of data structure being accessed; and 
5 a step for authorizing a requesting entity using the role templates in a manner 

that is independent of the type of data structure being accessed. 

32. A method in accordance with Claim 31, wherein the step for 
authorizing a requesting entity using the role templates comprises the following: 

an act of maintaining a plurality of role definitions that define access 
10 permissions for specific entities by using one or more of the role templates; 

an act of receiving a request from the requesting entity to perform at least one 
of the command methods, the request identifying the requesting entity; 

an act of identifying a role definition corresponding to the requesting entity; 

and 

15 an act of determining access permissions for the requesting entity with respect 

to the command method using the role definition corresponding to the requesting 
entity. 

33. A computer-readable medium comprising computer-executable 
instructions for performing the act and step recited in Claim 31. 

20 34. A computer program product for use in a computer network that 

includes different types of data structures, the computer program product for 
implementing a method for authorizing a requesting entity to operate upon data 
structures in a standard manner, the computer program product comprising one or 
more computer-readable media have stored thereon the following: 

25 computer-executable instructions for maintaining a plurality of role templates 

that define basic access permissions with respect to one or more command methods, 
wherein at least some of the role templates define access permissions in a manner that 
is independent of the type of data structure being accessed; 

computer-executable instructions for maintaining a plurality of role definitions 

30 that define access permissions for specific entities by using one or more of the role 
templates; 
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computer-executable instructions for detecting the receipt of a request from 
the requesting entity to perform at least one of the command methods, the request 
identifying the requesting entity; 

computer-executable instructions for identifying a role definition 
5 corresponding to the requesting entity; and 

computer-executable instructions for determining access permissions for the 
requesting entity with respect to the command method using the role definition 
corresponding to the requesting entity. 

35. A computer program product as recited in Claim 31, wherein the one 
1 0 or more computer-readable media are physical storage media. 

36. In a computer network that includes different services, applications, 
and an authorization station, the applications submitting requests to perform 
operations on different data structures managed by the different services, a system for 
isolating the authorization process from the services so that the services need not 

15 independently authorize each request they receive from the number of applications, 
the system comprising: 

a plurality of services, each service configured to facilitate operations on one 
or more types of data structures; 

an authorization station configured to receive requests from a number of 
20 applications to operate upon data structures managed by any of the number of 
services, the authorization station configured to perform the following: 

receive a request to perform a target operation upon a target data 
structure managed by a target service; 

in a manner that is independent of the data structure desired to be 
25 operated upon, determine that the corresponding requesting entity is 

authorized to perform the target operation on the target data structure; and 

communicate to the target service that the requesting entity is 
authorized to perform the target operation on the target data structure. 
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